A wizard-type user interface (or simply “wizard” for brevity) refers to a user a interface that assists a user in completing a task via one or more user interface pages. The user interface pages establish a mechanism for interacting with the user through which the user enters and/or receives information in an ordered sequence of steps. Hence, wizards are particularly useful in guiding a user in completing a complex task that might otherwise be difficult for the user to perform in unassisted fashion. Wizards have been applied to many different kinds of tasks. For instance, wizards are commonly used to create or configure various objects, format various objects (such as tables or paragraphs), and so on.
FIG. 1 shows an exemplary wizard 100 that includes six pages (102-112). A first page 102 includes a title bar 114 that identifies the purpose of the wizard 100. That is, the title bar 114 provides a caption that identifies the main task performed by the wizard 100 (in this case, “Wizard Task XYZ”). The first page 102 also commonly includes additional introductory information 116 that describes the purpose of the wizard 100. User interface control buttons 120 and 122 provide navigation functionality used to navigate though the wizard 100. The “next” button 120 advances to a subsequent page in the sequence of pages provided by the wizard 100. A cancel button 122 aborts the wizard 100 without sequencing through the remainder of the pages. Further, in later-displayed pages, a “back” button is used to advance to a preceding page in the sequence of pages provided by the wizard 100.
The wizard 100 displays the second page 104 when the user activates the “next” button 120 of the first page 102. The second page 104 and subsequent pages typically prompt the user to make various selections, enter requested information, or perform other actions in an ordered sequence of steps. These pages commonly include a title section that identifies the respective subtasks assigned to the pages For instance, the second page 104 includes a title section 124 that identifies the purpose of the second page 104. The second page 104 also includes a main body section that includes prompting information 126. The prompting information 126 consists of text and/or graphics that prompts the user to perform some action. The second page 104 also includes one or more controls used to receive the user's input. The second page 104 specifically shows the exemplary use of a data entry box 128 for entering textual information in response to the prompting information 126. However, wizard pages typically draw from a wide variety of user interface controls to receive information from users. For example, the third page 106 uses a check box 130 to receive the user's selection. The fourth wizard page 108 uses radio buttons 132 (also know as option buttons) to receive input from the user. Both check boxes 130 and radio buttons 132 are useful for allowing the user to make binary-type selections (e.g., YES/NO-type selections) and/or to select one or more items in a list of items, to name just two exemplary common uses. Still other forms of user interface controls can be used to collect information from users, such as drop-down menus, scrollable selection fields, hypertext fields, and so on.
Many wizards sequence through pages in a singular and fixed order. That is, as shown in FIG. 1, the second page 104 necessarily follows the first page 102, the third page 106 necessarily follows the second page 104, and the fourth page 108 necessarily follows the third page 106. However, other wizards may deviate from this strict sequence in various ways. For example, in the example of FIG. 1, the fourth page 108 prompts the user to select between option A and option B. If the user selects option A, then the wizard 100 will advance to the fifth page 110 via path 134. If the user selects option B, then the wizard 100 will advance to the alternative fifth page 136 via the path 138. Other wizards may employ more complex branching scenarios, for example, presenting more than two choices. Other variations on the strict sequential ordering of wizard pages are possible. Navigation through some wizards ultimately resolves into a predetermined number of well-defined page sequences Other wizards can provide a more dynamic and open-ended set of navigational options to the user.
Finally, a sixth page 112 represents the terminal page in the wizard 100. The final page 112 commonly employs closing information 140 that presents various concluding remarks. The user can exit the wizard 100 at this point by activating a “finish” button 142.
FIG. 2 shows a technique for linking wizard pages together. Each wizard page typically includes logic associated therewith. Among other information, the logic can include program code that governs the behavior of each page, as well as formatting information that specifies the visual appearance of each page. In FIG. 2, an exemplary wizard 200 includes a first page having logic 202 associated therewith, a second page having logic 204 associated therewith, a third page having logic 206 associated therewith, and an nth page having logic 208 associated therewith. In the technique shown in FIG. 2, instructions used to carry out the linking between pages are embedded within the logic associated with individual pages. For example, logic 202 includes instructions 210 used to sequence to the second page. Logic 204 includes instructions 212 used to return to the first page, and instructions 214 used to advance to the third page. Logic 206 includes instructions 216 used to return to the second page, and instructions 218 used to advance to the nth page. Logic 208 includes instructions 220 used to return to a preceding page, and instructions 222 used to terminate the wizard 200.
The above-described technique suffers from a number of drawbacks. For example, the technique makes it difficult to modify the wizard 200. For example, suppose that a developer wanted to replace one or more pages in the wizard 200 with updated pages. This would require the developer to determine the linking information used in the original pages (e.g., the “back” and “next” instructions) and duplicate this linking information in the updated pages. In addition, the developer must review the existing pages in the wizard (i.e., the pages that have not been modified) to determine if they contain reference to any new or updated pages. If so, these pages may need to be modified to ensure that they link correctly to the new or updated pages. These editing tasks may be burdensome as well as susceptible to coding errors, as it requires the developer to delve into the code used in individual pages to ensure that the pages are threaded together in a desired manner. The technique shown in FIG. 2 also makes it difficult for a developer to export portions of one wizard into other wizards. More specifically, a series of pages from one wizard cannot be simply “plugged” into another wizard. Rather, using the technique of FIG. 2, the developer must modify the code associated with individual pages such that newly added pages properly link to existing pages in the other wizard; more specifically, this task may require the developer to modify both the code associated with the newly added pages and the code associated the existing pages in the other wizard. Again, this page specific implementation of linking behavior can be tedious and susceptible to coding errors.
As such, there is an exemplary need in the art for a more efficient technique for implementing the linking between pages in a wizard-type user interface.